Description

This PR disables sleep on a user's device for the duration of any Card Reader software updates.

Steps to reproduce

1. Set Xcode to use the simulated reader, and set Terminal.shared.simulatorConfiguration.availableReaderUpdate = .required in the StripeCardReaderService
2. Add breakpoints in StripeCardReaderService.reader(_:didStartInstallingUpdate:cancelable:) and StripeCardReaderService.reader(_:didFinishInstallingUpdate:error:)
3. Launch the app and connect to a reader
4. Observe that the sleep timer is disabled and enabled as expected.

Testing information

The shortest auto-lock is 30s – this is longer than it takes to complete a (simulated) reader update, but using a timer to trigger the connection allowed me to check that it doesn't autolock during a (real) update, and does after the update completes.

I added DispatchQueue.main.asyncAfter(deadline: .now() + 22) in a Task in CardReaderConnectionController.onFoundReader(). I used 22 seconds to give it time to connect and start the update before the sleep timer kicks in – we don't disable device sleep until the install actually starts.

It's important to note that the device won't sleep while connected to the Xcode debugger regardless of what you do, so timer-based testing should be done without a connection to Xcode. This means you need a reader which has a pending update to test in this way, as the Stripe simulated readers only work when you're connected to Xcode.

If you have such a reader, be sure to cancel any updates before they complete!

Also it's best to turn of Settings > Face ID > Attention Aware Features to ensure you're not keeping your phone awake by looking at it.

StripeCardReaderService isn't unit tested due to the difficulties presented by faking the Stripe SDK.

Screenshots

Before

After

Note that after the reader update is cancelled, the phone is allowed to go to sleep again, so 30s after the cancellation, the display goes to sleep in this second video.

• I have considered if this change warrants user-facing release notes and have added them to RELEASE-NOTES.txt if necessary.

Reviewer (or Author, in the case of optional code reviews):

Please make sure these conditions are met before approving the PR, or request changes if the PR needs improvement:

• The PR is small and has a clear, single focus, or a valid explanation is provided in the description. If needed, please request to split it into smaller PRs.
• Ensure Adequate Unit Test Coverage: The changes are reasonably covered by unit tests or an explanation is provided in the PR description.
• Manual Testing: The author listed all the tests they ran, including smoke tests when needed (e.g., for refactorings). The reviewer confirmed that the PR works as expected on all devices (phone/tablet) and no regressions are added.